View IXP1240_2761882.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

intel ? IXP1240 network processor specification update march 2004 notice: the IXP1240 may contain design defects or errors known as errata. characterized errata that may cause the IXP1240?s behavior to deviate from published specifications are documented in this specification update. part number: 278505-005 ( datasheet : )
ii specification update intel ? IXP1240 network processor information in this document is provided in connection with intel ? products. except as provided in intel?s terms and conditions of sale for such products, intel assumes no liability whatsoever, and intel disclaims any express or implied warranty relating to sale and/or use of intel products, including liability or warranties relating to fitness for a particular purpose, merchantability, or infringement of any patent, copyright, or other intellectual property right. intel corporation may have patents or pending patent applications, trademarks, copyrights, or other intellectual property right s that relate to the presented subject matter. the furnishing of documents and other materials and information does not provide any license, express or implied, by estoppel or otherwise, to any such patents, trademarks, copyrights, or other intellectual property rights. intel products are not intended for use in medical, life saving , life sustaining, critical control or safety systems, or in nuc lear facility applications. intel may make changes to specifications and product descriptions at any time, without notice. contact your local intel sales office or your distributor to obtain the latest specifications and before placing your product o rder. copies of documents which have an ordering number and are referenced in this document, or other intel literature may be obtaine d by calling 1-800-548-4725 or by visiting intel's website at http://www.intel.com. intel is a registered trademarks of intel corporation or its subsidiaries in the united states and other countries. *other names and brands may be claimed as the property of others. copyright ? 2004, intel corporation revision history revision date revision description 08/15/01 001 initial internal release. 12/14/01 002 update for the b0 stepping. 03/11/01 003 11/25/03 004 added errata 20. 03/25/04 005 added errata 21.
specification update iii intel ? IXP1240 network processor contents preface ........................................................................................................................ .......................5 summary table of changes....................................................................................................... ........7 identification information..................................................................................................... ...........10 errata......................................................................................................................... .......................11 specification changes.......................................................................................................... ............20 specification clarifica tions................................................................................................... ...........22 documentation changes .......................................................................................................... ........24
iv specification update intel ? IXP1240 network processor
specification update 5 intel ? IXP1240 network processor preface preface this document is an update to the specifications contained in the related documents table below. this document is a compilation of device and docu mentation errata, specifica tion clarifications and changes. it is intended for hardware system manufacturers and software developers of applications, operating systems, or tools. we have endeavored to include all documented erra ta in the consolidation process, however, we make no representations or warranties concerning the completeness of this specification update. information types defined in nomenclature are co nsolidated into the sp ecification update and are no longer published in other documents. this document may also contain information that was not previously published. related documents title part number IXP1240 network processor datasheet 278405 ixp1200 network processor family hardware reference manual 278303
6 specification update intel ? IXP1240 network processor preface nomenclature errata are design defects or errors. these may cause the published (component, board, system) behavior to deviate from published specifications. hardware and software designed to be used with any component, board, and system must consider all errata documented. specification changes are modifications to the current pu blished specifications. these changes will be incorporated in any new release of the specification. specification clarifications describe a specification in greater detail or further highlight a specification?s impact to a complex design situation. these clarifications will be incorporated in any new release of the specification. documentation changes include typos, errors, or omissions from the current published specifications. these will be incorporated in any new release of the specification. note: errata remain in the specification update throughout the product?s life cycle, or until a particular stepping is no longer commercia lly available. under these circum stances, errata removed from the specification update are archived and available upon request. specification changes, specification clarifications and documentation changes are re moved from the specification update when the appropriate changes are made to the appropri ate product specification or user documentation (datasheets, manuals, etc.).
specification update 7 intel ? IXP1240 network processor summary table of changes summary table of changes the following table indicates the errata, specifi cation changes, specification clarifications, or documentation changes which apply to the ixp1250 network processor product. intel may fix some of the errata in a future stepping of th e component, and account for the other outstanding issues through documentation or specification changes as noted. this table uses the following notations: codes used in summary table stepping x: errata exists in the stepping indicated. specification change or clarification that applies to this stepping. (no mark) or (blank box): this erratum is fixed in listed stepping or specification change does not apply to listed stepping. page (page): page location of it em in this document. status doc: document change or update will be implemented. fix: this erratum is intended to be fixed in a future step of the component. fixed: this erratum has been previously fixed. nofix: there are no plans to fix this erratum. eval: plans to fix this erratum are under evaluation.
8 specification update intel ? IXP1240 network processor summary table of changes errata no. steppings page status errata a0 b0 ? ? 1 xx 11 nofix sram registers 2 xx 11 nofix csr access using pci memory cycles 3 xx 11 nofix pci_dma instruction 4 xx 12 nofix clock setup time 5 xx 12 nofix hold time issues for all pci signals (both bused and control) 6 xx 12 nofix ix bus contention in shared ix bus mode 7 xx 12 nofix tval max timing issues when running at 66 mhz for all pci signals 8 xx 13 nofix pci csr corruption 9 xx 14 nofix sram[write_unlock,..., burst_count] instruction 10 x 16 fixed pci_out_int_mask register bits not readable 11 xx 16 nofix spurious pci parity errors 12 x 16 fixed sdram arbiter 13 x 16 fixed problem with crc 14 x 16 fixed sdram_crc 15 x 17 fixed sa1200 software reset 16 xx 17 nofix branch and return 17 x 17 fixed pci parity error signal 18 x 18 fixed find bit 19 xx 18 nofix sdram_crc residue register corrupted data 20 xx 19 nofix read-lock cam operations from the strongarm* core to sram 21 xx 19 nofix 66 mhz capable bit
specification update 9 intel ? IXP1240 network processor summary table of changes specification changes no. steppings page specification changes a0 b0 ? ? 1 xx 20 sram bus signal timing parameters 2 xx 20 sdram bus signal timing parameters 3 xx 20 fclk ac parameter measurements 4 xx 20 sram sclk signal ac parameters 5 xx 21 sdram sdclk ac parameters specification clarifications no. steppings page specification clarifications a0 b0 ? ? 1 xx 22 sram unlocks and write unlocks 2 xx 22 maximum number of chain_ref instructions 3 xx 22 dma receive in big endian mode documentation changes no. page documentation changes none for this release
10 specification update intel ? IXP1240 network processor identification information identification information markings product name stepping qdf number marketing part number versio n gcIXP1240ac 1 1. samples only. a0 q254 837510 232 mhz gcIXP1240ac 1 b0 q253 837153 232 mhz gcIXP1240aa b0 na 837150 166 mhz gcIXP1240ab b0 na 837151 200 mhz gcIXP1240ac b0 na 837152 232 mhz figure 1. package marking a8906-02 pin 1 i gcIXP1240xx ffffffff intel m c 2001 xxxxxxxsz yww phillippines bsmc (alt# & date code, coo) fpo # intel legal name
specification update 11 intel ? IXP1240 network processor errata errata 1. sram registers problem: reads of the sram_boot_config and sram_slowport_config registers return the two inner bytes out of order. sram_boot_config: written as: brwa bcea brwd bced read as: brwa brwd bcea bced sram_slowport_config: written as: srwa scea srwd sced read as: srwa srwd scea sced implication: bytes are read out of order. workaround: software that reads these registers need s to put the bytes in the correct order. status: nofix 2. csr access using pci memory cycles problem: the 128 byte window size is not supported. all other window sizes are valid. the csr_base_addr_mask[18] may only be set to 1, preventing the 128 byte window size from being selected. all other sizes are supported. implication: a 128 byte window size is not valid. workaround: use a different pci window size. status: nofix 3. pci_dma instruction problem: the microengine pci_dma instruction sdram address operand is misaligned. implication: incorrect addressing occurs if the address operand is not shifted. workaround: the sdram address operand of the pci_dma instruction requires a 1-bit right shift for proper quadword addressing. for example, the address of a descriptor pointer located at sdram address 0x1000 should be right-shifted 1 bit with the resulting operand value being 0x0800, as follows: ; fix address of sdram descriptor pointer immed[tmp1, 0x1000] alu[desc_addr,--,b,tmp1,>>1] ; issue dma request pci_dma[desc_addr, 0, any_queue] status: nofix
12 specification update intel ? IXP1240 network processor errata 4. clock setup time problem: because the sram and sdram setup times are di rectly related to the loading of sclk and sdclk, excessive setup times (t su ) may be seen under heavy loading conditions. the maximum value of t su for both memory interfaces is 7.5 ns. implication: inability to meet the data setup time specification for memory devices. workaround: buffer sclk and sdclk with a zero skew clock buffer such as a cypress cy2309. nofix 5. hold time issues for all pci signals (both bused and control) problem: the pci local bus specification, revision 2.2 , specifies a minimum hold time of 0 ns in section 7.6.4.2. the IXP1240 requires a minimum hold time of 1.0 ns (t h - input signal hold time from clk). implication: system designers must constrain their design to tighter than worst-case pci timing. one recom- mendation is to limit the trace length of the pci bus resulting in a reduction of tprop. workaround: none. status: nofix 6. ix bus contention in shared ix bus mode problem: in shared ix bus mode, using the tk_in pin to configure the initial ix bus owner and ready bus master mode could result in improper initialization. as a result, more than one IXP1240 may be the initial ix bus owner and ready bus master. implication: this erratum causes contention on the ix bus and th e ready bus. it is also possible that the devices could initialize to the opposite state (not initial ix bus owner, ready bus slave), in which case no device controls the ready bus as master. workaround: use software to configure the initial ix bus own er and ready bus master mode instead of using the tk_in strapping option. pulldown the tk_in inputs to all IXP1240s on a shared ix bus to inhibit initial ix bus owner and ready bus master mode. this ensures that no IXP1240 will be the initial ix bus owner and that all IXP1240s will be ready bus slaves. boot software can then initialize one IXP1240 to initial ix bus owner and ready bus master mode by writing rdybus_template_ctl[8]=1. it is recommended to perform this operation as quickly as possible after reset to minimize the length of time the ix bus and ready bus float. status: nofix 7. tval max timing issues when running at 66 mhz for all pci signals problem: the pci local bus specification, revision 2.2 specifies a maximum signal valid delay (tval) time of 6.0ns in section 7.6.4.2. the IXP1240 guarantees a worst-case tval maximum of 6.5 ns. implication: the tval maximum value of 6.5 ns requires a reduction in maximum flight time (tprop) when running at 66 mhz. workaround: system designers must constrain their design to tighter than worst-case pci timing. one recom- mendation is to limit the trace length of the pci bus resulting in a reduction of tprop. status: nofix
specification update 13 intel ? IXP1240 network processor errata 8. pci csr corruption problem: the pci csrs will be corrupted by any write access to the pci memory space, pci io space, or pci config space from the strongarm* core to the pci, if the previous transaction was a csr write to registers in the pci unit. the affected address ranges are: pci memory space (6000 0000 - 7fff ffff) pci i/o space (5400 0000 - 5400 ffff) pci config space 0 and 1 (5200 0000 - 53bf ffff) the problem is dependent on the sequence of strongarm* core transactions described above, and is not dependent on the time between these transactions. implication: erratic behavior of pci operations. the address of the register (pci csr) that gets corrupted during the pci memory access equals the lower ad dress bits of the pci memory transaction. workaround: always follow a write operation from the strongarm* core to any csr within the pci block by a read to a register within the pci. note: the read operation must immediat ely follow the write to the csr. the following is an example of a csr read to the pci_addr_extension 4200 0140h. apart from the device driver writing to pci, vxworks also writes to pci timer registers. to get around this: 1. insert the following piece of code into the header file IXP1240eb.h located in the IXP1240 developer?s workbench software installation in the directory boardsupport\vxworks\IXP1240eb . #ifdef pci_workaround #define amba_timer_write(reg, data) ({\ __asm__ __volatile (""); \ (*((volatile uint32 *)(reg)) = (data)); \ ((void)*(volatile uint32 *)(IXP1240_pci_addr_ext)); \ __asm__ __volatile (""); }) #endif 2. define the compiler directive pci_workaround , either in your project build settings or as a #define in the header file. without this directive, the compiler may reorder the instructions. 3. rebuild the vxworks image. refer to the readme file entitled building the vxworks bsp, for directions on how to build the image. status: nofix
14 specification update intel ? IXP1240 network processor errata 9. sram[write_unlock,..., burst_count] instruction problem: the sram[write_unlock,..., ref_ cnt] optional_token(s) instruction does not work correctly when ref_cnt > 1. note that the command work s correctly when the re f_cnt is equal to 1. implication: the sram[write_unlock,?,ref_cnt] command may not be completed by the sram unit when the ref_cnt is greater th an 1. instead a different sram command may get executed twice. this behavior is observed sporadically, when cer tain sequences of commands get queued to the sram unit. because the commands arrive at the sr am unit from different microengine threads, it is impossible to determine if a software using this mode of command is prone to failure, or, when it will fail. the exact symptoms observed by the user will depend on the system software design and implementation. for example, if the thread waits for the completion of the write_unlock command that gets dropped (either using the ctx_swap optional token, or, the sig_done optional token and ctx_arb[sram] command), then that thread will hang indefinitely. further, the write to the memory location will not complete leading to data corruption problems. and, because a different command gets executed twice, two sram signals may be generated to a different thread, leading to improper program flow and data corruption. it is recommended that the software programs not use the sram[write_unlock,?,ref_cnt] command with a ref_cnt > 1. if more than one long word needs to be written to memory, the software should use the workarounds described below. workaround: two workarounds have been developed and are described below: 1. break the sram[write_unlock,..., ref_cnt] in struction into a sram[write, ?, ref_cnt] and sram[write_unlock,..., 1] pair. workaround 1 requires two microengine instruction control store locations, but results in one extra sram bus write cycle. it is possible to eliminate the extra bus cycle by suitably modifying the transfer register, address, and, ref_cnt fiel ds, but may result extra microengine instructions needed to compute the address. a simple case is illustrated in the examples below for this. 2. break the sram[write_unlock,....], instruc tion into a sram[write, ?, ref_cnt] and sram[unlock,..., 1] pair. workaround 2 does not have the extra bus access but may require a third ctx_arb[sram] instruction if the program needs to wait for completion of the command. examples shown below will illustrate this point. note: great care must be taken to ensure that different optional tokens are carried over to the workaround to ensure correct program flow. the examples below are given to illustrate some key considerations. example a ? no optional tokens. original code sram[write_unlock, $x1, saddr, 0, 3] workaround 1 sram[write, $x2, saddr, 1, 2] sram[write_unlock, $x1, saddr, 0, 1] workaround 2 sram[write, $x1, saddr, 0, 3] sram[unlock, --, saddr, 0, 1]
specification update 15 intel ? IXP1240 network processor errata example b ? ctx_swap optional token. original code sram[write_unlock, $x1, saddr, 0, 3], ctx_swap workaround 1 sram[write, $x2, saddr,1, 2] sram[write_unlock, $x1, saddr, 0, 1],ctx_swap workaround 2 sram[write, $x1, saddr, 0, 3], sig_done sram[unlock, --, saddr, 0, 1] ctx_arb[sram] example c - when the priority queue is used, both requests must use the same queue. original code sram[write_unlock, $x1, saddr, 0, 3], priority, ctx_swap workaround 1 sram[write, $x2, saddr, 1, 2], priority sram[write_unlock, $x1, saddr, 0, 1], priority, ctx_swap workaround 2 sram[write, $x1, saddr, 0, 3], priority, sig_done sram[unlock, --, saddr, 0, 1], priority ctx_arb[sram] example d ? correctly handling the defer optional token. original code alu[$x1, --, b, r1] alu[$x2, --, b, r2] sram[write_unlock, $x1, saddr, 0, 3], ctx_swap, defer[1] alu[$x3, --, b, r3] workaround 1 alu[$x1, --, b, r1] alu[$x2, --, b, r2] alu[$x3, --, b, r3] sram[write, $x2, saddr, 1, 2] sram[write_unlock, $x1, saddr, 0, 1], ctx_swap workaround 2 alu[$x1, --, b, r1] alu[$x2, --, b, r2] alu[$x3, --, b, r3] sram[write, $x1, saddr, 0, 3], sig_done sram[unlock, --, saddr, 0, 1] ctx_arb[sram] status: nofix
16 specification update intel ? IXP1240 network processor errata 10. pci_out_int_mask register bits not readable problem: pci out interrupt mask register at 34h. the register is write only and cannot be read back. implication: the mask is operational, but the only way to test it is by generating i 2 0 and doorbell interrupts to pci, writing 1 to this register, and then checking if subsequent interrupts to pci are masked. workaround: none. status: fixed 11. spurious pci parity errors problem: after initialization, the IXP1240 may indicate spurious pci parity errors until at least 32 longwords have been transferred to the pci bus using a target read mechanism. implication: pci parity errors may occur in the first 32 longwords during a target read. workaround: the pci bus initialization logic should include a 32 longword (or more) target read operation to each IXP1240. during this interv al, ignore pci parity errors. status: nofix 12. sdram arbiter problem: commands are dropped in the sdram controller when using sdram[], optimize_mem chip would ?hang? due to a lockout condition in the sdram arbiter a specific sequence of dram commands to different queues would ev entually cause the arbi ter to not grant any command that isn?t intended for the high priority queue. implication: using the optimize_mem token on sdram references may freeze microengines workaround: don?t use opt_mem queue with sdram references status: fixed 13. problem with crc problem: problem with crc when data not is not 64-bit aligned. crc calculation over unaligned data from dram to tfifo was not calculated correctly. data was also not making it to the tfifo correctly. the problems occurred with and without crc masking, and on all burst sizes. implication: requires additional instructions to align data, thus preventing atm oc12 speed. workaround: none status: fixed 14. sdram_crc problem: sdram_crc instruction hangs the IXP1240. the IXP1240 appears to hang while doing sdram[read ], read_crc. the problem here is that during an sdram chain, a non-dram instruction woul d interleave itself on the command bus right before the last sdram reference in the chain. this caused the chain reference to stop and the last sdram reference (which had a ctx_swap token) would not go into the ordered queue. so the chain is sitting there waiting for the last reference, which will never arrive, and the ctx_swap would never return because its instruction will never get out of the queue. implication: can?t use crc.
specification update 17 intel ? IXP1240 network processor errata workaround: none status: fixed 15. sa1200 software reset problem: pci-sa1200 reset register does not function as specified. three mechanisms are used to reset the IXP1240: two hardware inputs (pci_rst# and reset_in# ) one software reset (sw) via the ixp1200_reset register. problems have been observed in attempting to reset the IXP1240 via the pci_rst# input or the ixp1200_reset register (sw reset). in summary: 1. reset_in#: no reported problems with the IXP1240 hardware reset. 2. pci_rst#: does not work per the specification. it does not reset the device correctly and results in a hang condition during the boot sequence. 3. ixp1200_reset register: unpredictable results. specifically customers initiating a soft reset by writing a value of 0xffffffff to this register results in the IXP1240 hanging during the boot sequence. implication: hangs the system, typically after running for a period of time. workaround: none status: fixed 16. branch and return problem: certain sequence of instructions will cause dropping of an instruction following the return instruction. a rtn or jump may not follow a branch whose branch decision is made at the p3 pipeline stage. these branches include all class 3 branch instruc tions and branches where the decision has been postponed to the p3 stage. please see section 4.5.1 (class 3 instructions) and section 4.5.4 (postponed branch decision) of the ixp1200 network processor family hardware reference manual and sections 3.20 and 3.29 of the ixp1200 network processor family programmers reference manual for more information. implication: a program execution failure will occur. workaround: a rtn or jump may not follow a p3 stage branch; program accordingly. status: nofix 17. pci parity error signal problem: parity error signal not asserting. the parity bit in the pci interface is not set co rrectly. the parity error indication bit in the pci_status register is correct. implication: bad parity. workaround: use the register parity error indication in the pci_status register. status: fixed
18 specification update intel ? IXP1240 network processor errata 18. find bit problem: find bit works on the software model but not in the actual hardware. the operation returns zero when a non-zero result is expected. ; demonstration of find_bset_with_mask erratum ; ; the data register is loaded with all 1?s ; then we do a find_bset_with_mask with a mask of 0x10, ; which should find bit 4 as the first bit set. ; on hardware, the result comes back as zero indicating no bit set. immed[data, -1] find_bset_with_mask[0x10, data], clr_results nop nop nop nop nop nop load_bset_result1[result] ; should result in 0x104 nop nop nop lab#: br [lab#] implication: wrong find bit. workaround: do not use the find_bset_with_mask instruction with an immediate mask operand. status: fixed 19. sdram_crc residue register corrupted data problem: an sdram_crc[write, ..], initiate command, under certain conditions, may result in corrupted data in the residue register. implication: during an alignment operation of >=4 bytes, an ad ditional cycle is required for the operation to complete when compar ed to an alignment of < 4 bytes. if an sdram_crc[write, ..], initiate command is issued immediately after an alignmen t operation of >= 4 bytes, when the alignment is not part of a crc chain, the additional cycle bloc ks the crc residue register write resulting in a corrupted residue value. workaround: two software workarounds exist for software designs doing both sdram[tfifo_wr, ]byte-align>=4 and crc calculations sequences. the workar ounds insert one cycle between the last sdram[tfifo_wr, ]byte-align>=4 and the sdram_crc[write],initiate that immediately follows. workaround 1: this workaround is recommended due to the ease of implementation. an extra cycle between all read and wr ite operations is effected by programming the read-write turnaround time(trwt) value in the sdram csr register to at least 0x2. the trwt value of 0x2 places two unused cycles on the sdram pins be tween every read and write, as opposed to the required one. the simulator will detect if this problem could occur in the simulating program and will print a warning if workaround 1 is not used. workaround 2: the workaround is to always insert a regular sdram read without any byte alignment immediately before the crc initiation. an example of this workaround is to chain an sdram[read] to every sdram[tfifo_wr],byte-align>=4 and to place these requests in any queue
specification update 19 intel ? IXP1240 network processor errata except the ordered queue. this queue allocation is not a requirement, only a recommendation for possible performance implications. no additional cycles are inserted in this workaround if the instruction sequences are valid program design goals. status: nofix 20. read-lock cam operations from the strongarm* core to sram problem: strongarm* core instructions that use the sram cam address range (0x1200 0000 - 0x127f ffff) to perform a read-locked access can not rely on the lock attempt succeeding. implication: strongarm* applications that share data structur es with the microengines cannot rely on the sram cam to provide atomic access to those data structures. when a strongarm* application issues a read_lock operation, the operation may be placed in the read_lock fail queue by the sram controller. the application determines whether or not the operation was placed in the read_lock fail queue by checking the value of the rls bit of the sram_csr register. to determine when a failed read_lock request is eventually moved from the read_lock rail queue to the cam, the application polls the sram_csr register until the rlrs bit is set to 1. the sram controller is incorrectly failing to set the rlrs bit when read _lock operation is moved from the read_lock fail queue to the sram cam. therefore, a strongarm* application is not notified when a read_lock request is ultimately granted. this will cause locks to be placed in the cam without application awareness. workaround: none. if a mutual exclusion mechanism is require d, the following approaches may be used in place of the sram cam: 1. use the sram bit test & set and bit test & clear atomic operations (refer to errata 32). 2. create a microengine service thread that will access the sram cam on behalf of the strongarm* application. for information on building a service thread that is callable from the strongarm* core refer to the description of the shrimp api and dispatch library in the ixp1200 network processor family microcode software reference manual . status: nofix 21. 66 mhz capable bit problem: the IXP1240 is 66 mhz capable, but the 66 mh z capable bit (bit 21) in the pci_cmd_stat register is incorrectly fixed to zero indicating that it is not capable of 66 mhz operation. implication: when this bit is read, the IXP1240 incorrectly indicates that it is not capable of operating at 66 mhz as defined in the pci local bus specification, revision 2.2 . workaround: do not use this bit for determining the maximum operating frequency of the IXP1240?s pci bus. status: nofix.
20 specification update intel ? IXP1240 network processor specification changes specification changes 1. sram bus signal timing parameters the maximum clock to data output valid delay (t val ) value for 232 mhz operation was originally specified as 4.0 ns. the new t val value is 3.35 ns. the maximum clock to control outputs valid delay (t ctl ) value for 232 mhz operation was originally specified as 4.0 ns. the new t ctl value is 3.05 ns. the minimum data input setup time before sclk for pipelined srams (t sup ) value for 232 mhz operation was originally specified as 3.75 ns. the new t sup value is 3.10 ns. 2. sdram bus signal timing parameters the maximum clock to data output valid delay (t val ) value for 232 mhz operation was originally specified as 3.4 ns. the new t val value is 3.3 ns. the maximum sdclk to control output valid delay (t ctl ) value for 232 mhz operation was originally specified as 3.4 ns. the new t ctl value is 2.90 ns. t sup , the minimum data input setup time before sdclk value for 200 mhz operation was originally specified as 3.75 ns. the new t sup value is 3.70 ns. t sup , the minimum data input setup time before sdclk value for 232 mhz operation was originally specified as 3.75 ns. the new t sup value is 3.70 ns. 3. fclk ac parameter measurements the parameter values for t high , t low , and the t r and t f units have changed as follows: the minimum clock high time (t high ) was originally specified as 4.5 ns. the new t high value is 3.8 ns. the minimum clock low time (t low ) was originally specified as 4.5 ns. the new t high value is 3.8 ns. both t high and t low have been further clarified by the statement ?t high and t low are based on a 50% duty cycle and can vary worst case 45-55%?. the units used for clock rise (t r ) and clock fall (t f ) time was originally specified as v/ns. the new unit is ns. 4. sram sclk signal ac parameters the minimum cycle time (t cyc ) for 232 mhz operation was originally specified as 8.6 ns. the new t cyc value is 8.62 ns. the minimum cycle high time (t high ) for 232 mhz operation was originally specified as 4.6 ns. the new t high value is 4.02 ns. the minimum cycle low time (t low ) for 232 mhz operation was originally specified as 4.6 ns. the new t low value 4.02 ns.
specification update 21 intel ? IXP1240 network processor specification changes 5. sdram sdclk ac parameters the minimum cycle time (t cyc ) for 232 mhz operation was originally specified as 8.6 ns. the new t cyc value is 8.62 ns. the minimum cycle high time (t high ) for 232 mhz operation was originally specified as 4.6 ns. the new t high value is 4.02 ns. the minimum cycle low time (t low ) for 232 mhz operation was originally specified as 4.6 ns. the new t low value 4.02 ns.
22 specification update intel ? IXP1240 network processor specification clarifications specification clarifications 1. sram unlocks and write unlocks issue: documentation had indicated that performing an sram write_unlock on a memory location that was not locked would only result in an sram write, and that an sram unlock on a memory address that was not locked would result in no action. in actuality, unlocking an sram address that is not locked will result in corruption of internal cam pointer leading to unpredictable results. the internal cam pointer is implemented as a 4-bit counter which indicates the number of outstanding locks that are present in the cam. th e unlock/write_unlock of an address that is not present in the cam will incorrectly decrement this counter. this could result in corruption of cam contents and failure of read_locks which should have been successful. depending on the frequency of incorrect unlocks write_unlocks, and the overall program flow, this could result in data corruption, or eventual hang of one or more threads. 2. maximum number of chain_ref instructions issue: documentation has not adequately described that for sdram and sdram_crc instructions, the maximum number of instructions that may be chained together using the chain_ref optional token is five. chaining more than five instructions runs the risk of overflowing the sdram queues, resulting in dropped references. 3. dma receive in big endian mode issue: the documentation does not clearly describe the pc i receive operation when big endian data in is set. the fact that byte swapping occurs before th e data is aligned was not clearly articulated. the clarification in figure 2 will eliminate all ambiguities.
specification update 23 intel ? IXP1240 network processor specification clarifications figure 2. results for dma receive in big endian mode - unaligned transfer
24 specification update intel ? IXP1240 network processor documentation changes documentation changes none for this version of the specification update.

▲Up To Search▲

Price & Availability of IXP1240

	To Download IXP1240 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .